First collapsible open

I prefer to have the first collapsible open, because it immediately gives the user an impression of the page content. With everything collapsed, I'm afraid that the user's first impression can be that there is “not much to do” on the page.

I have sneakily closed this one, because I experienced by myself that I did not realize there were more settings for different items.

Having the overview of all the things that have settings gave me a much better idea of what can be controlled vs what can be changed for a post-type.
This is very easily discoverable by clicking open one of the collapsibles.

I also experienced that clicking one open, also made it super intuitive to close it.
Having one open, led mostly to having more open and thus a very cluttered screen I'm working in.

What are your opinions on this @thijsdevalk @jdevalk ?

Other design principles

Clicking through the plugin, I still think the paper padding of 16px looks a bit cramped on some pages... Maybe we should also still consider a padding of 24px. (like in our Sketch design)

I think @jdevalk / @thijsdevalk have a strong opinion on this. Leaving that open from my end.

These labels also differ in font-weight. On the Features tab, the font-weight is 500 and on the Webmaster Tools it’s 600. In our designs, all labels are in Semi Bold (600). I think we should strive for using two or three different font-weights (Normal 400 and Semi Bold 600 en eventually Light 300 for the purple H1/H2 headings) in the plugin.

When I compared the Sketch to what was rendering in my browser; the 500 font-weight matched the design a lot better. I think this is because browsers and design-programs render these things differently.
They were a bit chunky at 600 in my opinion.

In my opinion, leaving out the divider lines below the switches causes that the switches are floating too much. Especially on the Features tab. I can imagine for some people it might be hard to see the connection between the labels and the corresponding switches. (there is much space between them)

I do think they work very well on most places, the dividers were giving a lot of extra horizontal cognitive load and reduced scannability; especially inside the papers with inputs nearby.
I don't think we want to have dividers on some places and not on others, but we could consider an exception for the features list?

Adding to todo

• Some labels (for example setting labels on the Features tab) have the color #444, but this should always be #303030 (for example input field labels on Webmaster Tools) following our text styles.
• The yellow buy buttons have a font-weight of 300. Is that intended? I think they might be hard to read for some people. I would suggest using the same font-weight as for our other buttons (400) here.

@moorscode

When I compared the Sketch to what was rendering in my browser; the 500 font-weight matched the design a lot better. I think this is because browsers and design-programs render these things differently.
They were a bit chunky at 600 in my opinion.

I agree with that. As long as 600 is changed to 500 everywhere. ;)

I don't think we want to have dividers on some places and not on others, but we could consider an exception for the features list?

Ok, I think at least on the Features tab using the dividers would improve the usability a lot...

Looking at the single switches (when not in a list), I think they can use a bit more margin top and bottom... Maybe 24px instead of 16px?

@thijsdevalk do we also want to change the Enabled/Disabled into Enable {setting} Yes/No?

Adding to what @uxkai already shared:

Visual hierarchy and whitespace

In line with @uxkai's feedback; some sections feel a bit cramped or cluttered. This is due to a lack of visual hierarchy and whitespace in my opinion.

Papers and collapsibles

With everything being paperized, I fear it becomes too random which sections should be collapsible and which shouldn't be. What will be the reasoning/pattern behind it? E.g. when a page becomes too long/large, we divide it into collapsible sections?

Shifting alignment because of centered content

Because of the centered content there's some shifting of elements (see screenshot below). I agree with @uxkai and I'm worried that it might cause more problems than it solves. What was the reasoning behind centering it?

Interesting iteration! Love the attention to detail, and happy to see that all those padding/margin issues have been dealt with.

I agree with most points that have been raised above. The tradeoff between visual clarity, consistency and hierarchical clarity is tricky sometimes.

For instance, papers do bring organizational clarity but I feel like they also introduce visual noise. I keep missing the Save button that's wedged between the papers above and the upsell paper below it in Free. I think we once experimented with papers that only have a border, could be considered for a next iteration, those are a little 'lighter'.

For the notififations icon we could maybe use the bell icon, which was finally added to dashicons recently - after I requested it a year ago 😁 https://iconify.design/icon-sets/dashicons/bell.html

Other than that I don't immediately have any more points that haven't been mentioned above already.

Is it possible to change the hard purple color for the variables in the SEO title field?

Yes, what do we want?

Two proposals:

Note: This is still the "old" page design, but it's just to get an idea of how the variables will look on a whole page.

1. Change the purple background to #707070 (= our placeholder / meta text color):

2. The same styling as our secondary buttons, but without inset shadow:

It depends a bit on how much you want these variables to stand out from the rest of the interface...

@uxkai I really like the inset-shadow personally; can you also make a preview of how that would look in the metabox?
As changing the color would change there too (for consistency).

@luckickken The distinction between collapsibles and no collapsibles I made:

• If there are items of the same order; we can collaps them (Post-types, Taxonomies, Archives) - otherwise papers
• If there is only 1 item on a page, don't use a collapsible

@luckickken @uxkai

In line with @uxkai's feedback; some sections feel a bit cramped or cluttered. This is due to a lack of visual hierarchy and whitespace in my opinion.

I agree, what is you proposed solution?

Regarding @thijsdevalk remark for the "We recommend you set this to Yes":

We want to make sure the context is clear which setting this applies to.
@uxkai / @luckickken can you provide ideas for this?

We want to make sure the context is clear which setting this applies to.
@uxkai / @luckickken can you provide ideas for this?

We could show that line underneath the setting (see screenshot below). Also I would pose each setting as a question, with question mark.

@luckickken The distinction between collapsibles and no collapsibles I made:
If there are items of the same order; we can collaps them (Post-types, Taxonomies, Archives) - otherwise papers
If there is only 1 item on a page, don't use a collapsible

I like this.

I agree, what is you proposed solution?

@uxkai could you make a proposal to improve the visual hierarchy, like I mentioned here. So:

• Look at heading hierarchy inside the papers
• Use of whitespace (margins between heading and settings and in between settings)

@jip, @uxkai concerning the toggle labels; I think it's possible to rewrite all of them to a question where the options are always Yes/No.

A few examples:

• Date archives: Enabled/Disabled becomes Enable date archives? Yes/No
• Date in Google Preview: Hide/Show becomes Show date in Google Preview? Yes/No

This makes it more consistent and visually easier on the eye (no shifting toggles because of long labels). What do you think?

Date in Google Preview: Hide/Show becomes Show date in Google Preview? Yes/No

This has been applied.

Date archives: Enabled/Disabled becomes Enable date archives? Yes/No

Agree, like confirmation of Product on this.